1. Technical Field
The present invention relates to data storage and retrieval generally and more particularly to a method and system of generating a point-in-time image of at least a portion of a database.
2. Description of the Related Art
Information drives business. Companies today rely to an unprecedented extent on online, frequently accessed, constantly changing data to run their businesses. Unplanned events that inhibit the availability of this data can seriously damage business operations. Additionally, any permanent data loss, from natural disaster or any other source, will likely have serious negative consequences for the continued viability of a business. Therefore, when disaster strikes, companies must be prepared to eliminate or minimize data loss, and recover quickly with useable data. In order to avoid unnecessary downtime and data loss to the greatest degree possible, conventional data processing systems frequently use data replication, backup, and/or restoration to generate and utilize point-in-time (PIT) images of data. An “image” within the present description may include either an exact duplicate or replica of an element or alternatively, sufficient data related to an element (e.g., an exact duplicate of one or more sub-elements of an element) such that the element may be reconstructed.
The process of creating a PIT image of data may be initiated concurrently with or immediately following the generation or receipt of a request for such an image or alternatively may be initiated prior to the generation or receipt of such a request, such as where a storage element (e.g., disk group, disk, volume, plex, or the like) storing the data is “mirrored” using a mirror storage element which is subsequently separated or “broken off” at the point in time at which a PIT image is desired. Where the process of creating a PIT image is initiated concurrently with or following the generation or receipt of a request for such an image, subsequently occurring write operations or “updates” to the data may be queued before being applied to the data or the principle of copy-on-write (COW) may be used to preserve the state of the data prior the PIT image request.
The creation of a point-in-time image of part or all of a database presents a number of unique complications. Where a database or portion thereof is large in size, it is desirable to perform an associated PIT image creation operation (e.g., a backup copy operation) quickly to prevent the amount of required additional storage (e.g., for queued updates or COW data) or the amount of time where updates to the database or database portion are prohibited from growing too large. Where the structure (e.g., the components and their physical or logical relationship to one another) of a database is unknown, for example where data regarding such structure is proprietary, the creation of a PIT image has traditionally been performed using specialized utilities provided by the database management system (DBMS) provider or by applying a single data management resource type to all portions of a database.
FIG. 1 illustrates a block diagram of a data processing system including a backup utility for generating a point-in-time image of at least a portion of a database according to the prior art. Although backup and restoration may be thought of as separate processes, within the context of the present description the term “backup” can be considered to include both back up and restoration. Data processing system 100 includes a first node 102 including a primary volume 104 used to store a database 106 and a secondary volume 108 coupled to the first node 102. First node 102 of the embodiment of FIG. 1 further includes application software 110 (e.g., a database application) coupled to a database management system (DBMS) 112 which is in turn coupled to primary volume 104. DBMS 112 of the illustrated prior art embodiment may be coupled to primary volume 104 directly, using a file system 114 and/or volume manager 116, or using a backup utility 118 as described further herein. Backup utility 118 may be implemented as an independent element as illustrated in FIG. 1, or may be incorporated into one or more other elements (e.g., DBMS 112) of data processing system 100.
Using backup utility 118, a user may create a logical backup copy of database 106 or a portion thereof (e.g., a table space or partition) on secondary volume 108. Backup utility 118 receives a user-specified logical name (e.g., the logical name of the database to be backed up) and thereafter performs all operations necessary to generate the requested backup. Because only logical names are specified (e.g., a database name, table space name, or partition number), a user implementing backup utility 118 is not required to have any knowledge of the physical components of a database. For the same reason however, backup utility 118 may not be integrated with any other utilities or data management resources which require knowledge of such components and consequently may not take advantage of any newly developed PIT image creation techniques.
FIG. 2 illustrates a block diagram of a data processing system for generating a point-in-time image of at least a portion of a database using a split mirror according to the prior art. Data processing system 200 includes a first node 202 including a primary volume 204 used to store a database 206 and a secondary volume 208 coupled to the first node 202. First node 202 of the embodiment of FIG. 1 further includes application software 210 (e.g., a database application) coupled to a database management system (DBMS) 212 which is in turn coupled to primary volume 204. DBMS 112 of the illustrated prior art embodiment may be coupled to primary volume 204 directly and/or using a file system 214 and/or volume manager 216 as described further herein.
A “split mirror” is an identical and independent copy of one or more disk volumes that can be attached to the same or different node as the mirrored disk volume(s). A split mirror is created by first “mirroring” or duplicating all write operations or “updates” performed on a primary volume to a secondary volume (e.g., secondary volume 208). While split mirror creation in the illustrated system of FIG. 2 is performed by volume manager 216, mirroring and/or split mirror creation may be performed in hardware or software by any of a variety of data processing system elements (e.g., application software 210, DBMS 212, file system 214, or the like). A split mirror is generated by merely ceasing to mirror write operations to a particular secondary volume, thus creating a PIT image of one or more entire volumes.
While database backup operations using split mirrors may be integrated with other data management utilities, such integration is limited because each split mirror must necessarily be generated at the volume level. Volume-level backup requires that a copy of an entire volume is made even if only a small amount of data (e.g., one or more small files) is to be backed up. Consequently, available storage space may be wasted and the number of databases which may be backed up and/or the number of backup copies of a database which may be made may be limited.